ModelTalk: a Framework for Developing Domain Specific 

Executable Models * 



Atzmon Hen-Tov 



David H. Lorenz 



Lior Schachter 



Ponds Ltd. 
Glil Yam 46905, Israel 
atzmon@pontis.com 



The Open University of Israel 
108 Ravutski St., Raanana 43107, Israel 
lorenz@openu.ac.il 



Pontis Ltd. 
GUI Yam 46905, Israel 
liors@pontis.com 



Abstract 

Developing and maintaining complex, large-scale, product line of 
highly customized software systems is difficult and costly. Part of 
the difficulty is due to the need to communicate business knowl- 
edge between domain experts and application programmers. Do- 
main specific model driven development (MDD) addresses this dif- 
ficulty by providing domain experts and developers with domain 
specific abstractions for communicating designs. Most MDD im- 
plementations take a generative approach. In contrast, we adopt 
an interpretive approach to domain specific model driven devel- 
opment. We present a framework, named ModelTalk, that inte- 
grates MDD, dependency injection and meta-modeling to form an 
interpretive, domain specific modeling framework. The framework 
is complemented by tool support that provides developers with the 
same advanced level of usability for modeling as they are accus- 
tomed to in programming environments. ModelTalk is used in 
a commercial setting for developing a product line of Telco grade 
business support systems (BSS). 

Categories and Subject Descriptors D2.6 [Programming Envi- 
ronments]: Programmer workbench; D3.2 [Language Classifica- 
tions]: Extensible languages. Object-oriented languages 

General Terms Design, Languages 

Keywords Model driven development; Dependency injection; 
Meta-modeling; Executable model; Domain specific languages 

1. Introduction 

Modem business application development is complex. It involves 
several domains of expertise, dealing with both functional and 
extra-functional requirements, all complicating the communication 
between domain users and domain experts. Working with domain 
specific models alleviates some of this complexity by communicat- 
ing domain abstractions in designs. 

In this work, we present a framework, named ModelTalk, 
for developing domain specific executable models. An executable 
model 1171 1121 is a model that drives the execution of the system. 
The major virtue of an executable model is that changes in the 
model are automatically reflected in the system |24|. ModelTalk 
is an interpretive, domain specific modeling framework: the model 
is the primary source of the system; the desired behavior of the 
runtime system is achieved by interpreting the model. 

ModelTalk integrates the principle of domain driven devel- 
opment 1221 1 191 with the technique of dependency injection. De- 
pendency injection 1151 1101 is a mechanism for defining external 



dependency declaratively (e.g., as an object graph configuration in 
XML) that can be injected into the runtime system (e.g., into Java 
objects). The major virtue of dependency injection is that it sup- 
ports declarative changes. The system behavior can be modified by 
composing descriptions of object graphs (in XML), thus avoiding 
the long cycle of compile-pack-deploy that is required when the 
changes are done in code (in Java). 

The ModelTalk framework is complemented by tool sup- 
port 1 1 1]. An Eclipse |8| plug-in for ModelTalk provides devel- 
opers with the same advanced level of environment look-and-feel 
for modeling as they are accustomed to with programming. 

Outline The rest of the paper is structured as follows. Section[2] 
briefly reviews dependency injection by example, comparing a 
code driven to a model driven approach. In Section [3] we describe 
the high level architecture of ModelTalk and show how model- 
ing and coding are integrated to form a model driven development 
framework. In Section |4] we illustrate meta-modeling with Mod- 
elTalk. Assessment of the ModelTalk framework is brought in 
Section[5] 

2. Model Driven Dependency Injection 

In this section, we illustrate the concept of code driven dependency 
injection in the Spring [21 1 framework. We then contrast depen- 
dency injection in Spring with the concept of model driven depen- 
dency injection in ModelTalk. 

2.1 Code Driven Dependency Injection in Spring 

In Spring, the developer starts the development iteration cycle 
by working on the Java implementation. Instances {beans, in 
Spring's terminology) are then defined to customize the imple- 
mentation. As an example, consider the UM L do main model for 

The Java class 



* This research was supported in part by the Israel Science Foundation (ISF) 
under grant No. 926/08 and by the office of the chief scientist of the Israel 
Ministry of Industry Trade and Labor. 



an HTTP client system depicted in Figure 
HTTP .Client (Listing [TJ provides a sendReceive method for 
sending HTTP requests. The class has three private instance vari- 
ables: numberOf Retries and timeout are used for configuring 
its communication handling policy; URL is used for configuring the 
Internet address of the resource to be accessed. 

An XML bean in Spring is a description of an object graph. It 
is instantiated into Java objects at runtime. The XML excerpt in 
Listing |2] shows how one might use beans in Spring to customize 
the HTTP .Client class: 

1. RobustHTTP .Client defines an abstract instance I2II of 
HTTP_Client with high numerical values for timeout and 
for numberOf Retries. 

' The UML diagrams are for illustration only. Models in MODELTALK are 
expressed in XML. 



HTTP Client 
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URL: String 
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Figure 1. Domain model 



public class HTTP_Client { 
private long numberOfRetries = 0; 
private long timeout = 0; 
private String URL = null; 

public void setNumberOf Retries(long number) { 
this.numberOf Retries = number; 

} 

public void setTimeout(long timeout) { 
this.timeout = timeout; 

} 

public void setURL(String URL) { 
this.URL = URL; 

} 

public HttpResponse sendRecieveQ { 
HttpResponse result = null; 
//business logic 
return result; 

} 

} 

Listing 1. Class implementation in Java 



<bean id= "flobustHTTP_Client " class= "HrTP_Client " 
abstract= "true "> 
<property name= "niuiiberOffletries " value="8"/> 
<property name= "timeout " value="i5"/> 

</bean> 

<beaii id="Fast/frrP_ Client" class= "HTTP.Client " 
abstract= "true "> 
<property name= "niujiberOffletries " value="2"/> 
<property name= "timeout " value="2"/> 

</bean> 

<bean id= "PontisLogofietriever " cl as s="HrrP_ CI lent" 
parent = "FastHTTP_Client "> 
<property name="[7fiL" 

value= "ww.pontis . com/logo . bmp"/> 

</bean> 

Listing 2. XML beans in Spring 



public static void main(String[] args) 

throws Half ormedURLException { 
Generic ApplicationContext context=getSpring(); 
HTTP_Client httpClient = 

(HTTP_Client)context.getBean("PontisLogoRetriever"); 
HttpResponse response = httpClient. sendReceive(); 



//. 



} 



Listing 3. Client code in Java 



2. FastHTTP _Client defines an abstract instance of HTTP_Client 
with low numerical values for timeout and for numberOf- 
Retries. 

3. PontisLogoRetriever defines a concrete instance of HTTP _- 
Client by specializing FastHTTP .Client with the location 
for the logo bitmap. 

This form of customization works for simple as well as for arbi- 
trary complex object graphs. For simplicity, the example illustrates 
the use of Spring for configuring properties of primitive types. Gen- 
erally, however, the injected values may also be instances of user 
defined classes. 

Lastly, the Java excerpt in Listing [3] shows how a client code 
uses the Spring factory to instantiate an HTTP .Client with the 
desired configuration. 

2.2 Model Driven Dependency Injection in ModelTalk 

In ModelTalk, the developer starts the development iteration cy- 
cle by working on the model. ModelTalk uses the notion of a 
class definition in the model. Model class definitions are the pri- 
mary source in which the constraints for the XML beans and for the 
structure of the implementation code are defined. These constraints 
are reflected in the development tool immediately, providing the de- 
veloper with full support for auto-completion, consistency check- 
ing, and so on. 

The XML excerpt in Listing |4] is the model class definition of 
HTTP .Client (and its three model instances) in ModelTalk^ 
The definition informs the modeling tool about the existence of 
this class. This is in contrast to Spring, where one must have the 
Java class itself available. ModelTalk uses property name tags 
to provide domain specific syntax. 

Model driven dependency injection enhances the safety of the 
declarative change process. Class definitions in the model constrain 
the model objects, leading to early detection of errors. Changes 
to the model can be applied to the runtime system with a higher 
degree of confidence than in Spring, since they undergo consistency 
checking. 

In the next section we explain our model driven approach in 
more detail. 

3. The ModelTalk Concept 

The high-level architecture of ModelTalk (Figure |2j is simi- 
lar to the general architecture of integrated development environ- 
ments (IDEs). The source code processors (Figure |2ji) are repli- 
cated to provide similar processors for modeling (Figure[2]\). The 
architecture is implemented in an extensible IDE (Eclipse |8]) to 
yield an integrative model driven development environment. 

3.1 Model Sources 

In ModelTalk, model source files are textual and they are man- 
aged by the IDE just as other source files. The model sources com- 



^ We use a simplified dialect of ModelTalk concrete syntax. 
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Figure 2. High level architecture of ModelTalk: (A) model processors; (B) code processors 



<bean id="HTTP_Clieiit" class= "Class "> 
<properties> 
<property> 

<name>mimberQf Retries</name> 
<type>Long</type> 

<description>Nuinber of retries</description> 
</property> 
<property> 

<name>timeout</name> 

<type>Long</type> 

<description>Timeout in seconds</description> 
</property> 
<property> 

<naiiie>URL</name> 

<type>String</type> 

<description>The target URL</description> 
</property> 
</properties> 
</bean> 

<beaii id="RobustHTTP_Clieiit" clas s=" HTTP _C1 lent" 
abstract= "true "> 

<numberOf Retries>8</timeout> 

<t imeout > 1 5< /t ime out > 
</bean> 

<beaii id="FastHTTP_Client" class= "HTTP_Client" 
abstract= "true "> 

<nuinber Of Retries>2</t imeout > 

<t imeout >2</t imeout > 
</beaii> 

<beaii id= "PontisLogofletriever " class= "HTTP. Client " 
parent = "FastHTTP_Client "> 
<URL>www .pontis . com/logo .bmp</URL> 
</bean> 

Listing 4. Domain model in ModelTalk 



prise instances, classes and metaclasses. A domain specific model- 
ing language (DSML) 1 20 1 is formed by defining metaclasses and 
classes. In a typical scenario, the domain expert in the development 
team defines a DSML. Domain users then define models in this 
DSML. Since the modeling tools rely on class defined in the model 
rather than in the code, the modeling activity does not depend on 
the existence of implementation code. 

3.2 Model Compiler 

The model compiler is one of the model processors in the Mod- 
elTalk framework (Figure |2]l. It is implemented as an Eclipse 
builder plug-in. The compiler implements a dependency analysis 
algorithm to support incremental compilation. 

Upon a change to the model, the compiler is invoked to per- 
form cross-model validation. Object graphs in the model are val- 
idated against the corresponding model class definitions. This ac- 
tivity is analogous to how a compiler reports syntactical and cer- 
tain semantical errors. Since ModelTalk is a meta-level system, 
classes, too, undergo similar validation checks. Cross-checks are 
necessary because a change in one model element might invalidate 
other model elements (possibly in other model files). 

The model compiler also checks the conformance of the Java 
sources to the model 1 18|. When developing the code classes, the 
tool verifies conformance of the code structure to the model class 
definitions. Mismatches are reported as errors in the IDE standard 
problems view. 

3.3 Model VM 

The model VM is the runtime component of ModelTalk, which 
is analogous to the JVM. Its primary responsibility is to manage 
the relationships between model elements and Java elements. This 
includes object graph instantiation and a reflection API 1 14|. 

The model VM implements a dependency injection mechanism. 
When a client requests a model instance, the Model VM finds the 
corresponding Java class, instantiates it, and injects the model prop- 
erty values into the Java instance variables. This is applied recur- 
sively for injected value of a complex type. The Model VM algo- 



rithm for mapping model classes to Java classes permits "holes," 
i.e., a model class without a Java counterpart. In such a case, the 
class is called declarative and mapped instead to the superclass in 
the Java model. This adaptability enables to make changes to the 
model at runtime without needing to also change the Java model. 

When a client requests a model class, the Model VM follows 
the same routine, thus enabling runtime modifications to the model. 
This is possible because ModelTalk's meta-meta-model itself is 
implemented in ModelTalk. 

3.4 The User Experience in Modeling 

The modeling user experience is similar to the user experience in 
programming. We use a commercial third-party XML editor as our 
model editor. The model editor provides auto-completion based 
on XML schema (XSD) generated from the model by the model 
compiler. Model elements are maintained in multiple source files 
arranged in folders by XML namespaces. 

Model compilation is incremental, providing the user with short 
response time. Model compilation is done across all model files. Er- 
rors are reported to the developer using the standard IDE problems 
view. The developer can navigate to the erroneous model element 
by double clicking on the error |T |. 

The Eclipse plug-in provides numerous views of the model 
(e.g., type hierarchy) and provides navigation capabilities both be- 
tween model elements themselves and between the model elements 
and corresponding Java elements. In addition, the plug-in provides 
refactoring facilities (e.g., rename) that propagate the changes to 
the Java source as well. Model source files are managed in a cen- 
tral repository (CVS) as other source files. 

4. Meta-modeling with ModelTalk 

In this section we illustrate the domain specific modeling capabil- 
ities of ModelTalk by extending the HTTP client example pre- 
sented in Section |2] Suppose we would like to cache data in order 
to reduce network traffic and to improve the overall response time. 
Lets assume the application uses HTTP .Client to retrieve different 
kinds of data: pictures, news, stock quotes, etc. Obviously, vari- 
ous kinds of data require different caching policies. For example, 
pictures can be cached for longer periods than news, while stock 
quotes shouldn't be cached at all. 

4.1 Declarative Classes 

Implementing the caching code in Java in each of these classes 
would require the expertise of a Java developer. Instead, we can 
define a metaclass MetaCache with a cache property of type 
CacheManager (Figure [5] and Listing |5j. The CacheManager 
provides cache management services at runtime. The methods 
getFromCache and putlnCache are defined in the CacheManager 
class in Java. For brevity, the CacheManager and StandardCache 
classes are not shown in the listing. 

We now make the HTTP .Client class an instance of MetaCache. 
The sendReceive method in HTTP .Client may then use the 
MetaCache metaclass to access the cache (Listing [6]l. We can 
further define specific HTTP client classes, PictureRetriever, 
NewsRetriever, and StockQuoteRetriever (Figure |4] and 
Listing [tJ, by subclassing HTTP_Client. Note that Picture- 
Retriever, NewsRetriever, and StockQuoteRetriever are 
declarative (without a counterpart in Java). 

4.2 Customizing a Metaclass 

Next, we enhance the example to demonstrate how architec- 
tural definitions are enforced by ModelTalk. Suppose our ap- 
plication needs to display bank account balances that are also 
retrieved using HTTP. Since bank account information is pri- 
vate, its confidentiality should be kept. We therefore have to 
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Figure 3. Domain model with a custom metaclass 



<bean id= "MetaCache" class= "Class " parent= "Class "> 
<properties> 
<property> 

<naine>cache</name> 
<type>CacheManager</type> 

<description>Caches the result</description> 
</property> 
</properties> 
</bean> 

<bean id="HTTP_Clieiit" class="MetaCacJie"> 
<cache class="StandardCaclie"> 
<timeToLive>60</timeToLive> 

<maxElementsInMemory>500</maxElementsInMemory> 
</cache> 
<properties> 

</properties> 
</bean> 

Listing 5. ModelTalk sources with a custom metaclass 



public HttpResponse sendRecieve() { 
MetaCache myMetaclass = 

(MetaCache)Kernel.instance().getClass(this); 
HttpResponse result = 

myMetaclass. getCache().getFromCache(getURL()); 
if (result == null) { 
// do the business logic using timeout & numberOfRetries 
myMetaclass. get Cache().putInCache(getURL(), result); 

} 

return result; 

} 

Listing 6. Accessing a metaclass in Java 
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Figure 4. Expanding the domain model with different types of resources 



<bean id= "Pi cturefletri ever" class= "MetaCaclie " parent="HrTP_Clieiit" declarative="true"> 
<cache class="StandardCacJie"> 
<timeToLive>600</timeToLive> 

<maxElementsInMemory>1000</maxElementsInMemory> 
</ cache> 
</bean> 

<beaii id= "Wewsfietriever " class= "MetaCaciie " parent= "HrrP_Clier!t " declarative="true"> 
<cache class="StandardCaciie"> 
<timeToLive>10</timeToLive> 

<maxElement s InMemory> 10000</maxElement sInMemory> 
</cache> 
</beaii> 

<bean \A= " St ockQuoteRetr lever" class="MetaCacJie" parent= "HTTP. Client " declarative="true"> 
<cache class="StandardCacJie"> 
<timeToLive>0</timeToLive> 

<maxElement s InMemory>0</maxElement s InMemory> 
</cache> 
</bean> 

<beaii \6="Cm_NewsRetr±ever" class="NewsRetriever" parent= "FastHTTP_Client"> 

<URL>www . cnn . com</URL> 
</bean> 



Listing 7. The resource retrieving model in ModelTalk 
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Figure 5. Expanding the domain model with secured cache 



<bean id="MetaSecuredCaciie" class= "Class" 

parent= "MetaCache " declarative= "true "> 
<properties> 
<property> 

<name>cache</naine> 
<type>SecuredCacheManager</type> 
<description>Provides secured caching 
capabilities</description> 
</property> 
</properties> 
</beaii> 

<beaii id= "BankBalanceRetriei^er " 
class= "MetaSecuredCache" 
pareiit= "HTTP_Client " declarative= "true "> 
<cache class= "SecuredCacheManager "> 
<timeToLive>10</timeToLive> 

<maxElementsInMemory>20</maxElementsInMemory> 
</cache> 
</bean> 

Listing 8. The secured cache model in ModelTalk 



make sure that only a secured cache manager is used in such 
cases. To achieve this we define MetaSecuredCache that ex- 
tends MetaCache and overrides the type of the cache property 
to SecuredCacheManager, which is a subclass of CacheManager 
(Figure |5] and Listing [Sj. BankBalanceRetriever is defined as 
instance of MetaSecuredCache and is therefore required to sup- 
ply an instance of a SecuredCacheManager for its cache property; 
otherwise, a model compilation error will be issued. For the sake 
of brevity, we do not show the corresponding changes in the Java 
code. 

Custom metaclasses (51 !6| define class level properties, which 
constrain the domain classes using domain terminology. Unlike 
class level members in Java (static members), metaclass properties 
allow subclasses to have different values for the metaclass proper- 
ties. 



The model contains objects, classes and metaclasses in a single 
type system. The same injection mechanism that works on objects 
is applied to classes as objects of their metaclasses. Since Java does 
not support metaclass extensibility, the metaclasses in the model 
are mapped to regular Java classes and the model VM manages the 
instance-of relation in the runtime system. 

5. Assessment 

The ModelTalk development platform has been used at Pontis 
by a team of over 20 developers for the last two years. Numerous 
customer projects were developed, delivered and deployed success- 
fully, satisfying requirements for hundreds of transactions per sec- 
ond. In this section we describe our subjective observations from 
using ModelTalk in a commercial product development environ- 
ment. 

Since the inception of the platform, we have been continuously 
running code measurements in order to indicate the platform's level 
of adoption within the R&D organization. Currently, the model 
contains approximately 4800 classes, of which 200 are metaclasses. 
There are tens of thousands of instances and 275K lines-of-code in 
XML. The average Depth of Inheritance (DIT) of model classes 
is 4.75. The XML schema of the application model (generated 
XSD) is 200K lines-of-code. 90% of the application Java source 
code is governed by the model (i.e., the classes are defined in the 
model). 82% of the source lines-of-code in customization projects 
are declarative. 

5.1 Developer Perspective 

Developers give very positive feedback, mostly concerning the dra- 
matic improvement in cycle times. An incremental model change 
takes no more than a few seconds on large models, compared to 
minutes, at best, in generative MDD (e.g., 1231 p. 256] and |23] P- 
261]). 

Users appreciate the Java-like usability of ModelTalk and 
the fact that modeling and programming are done in a single, inte- 
grated environment. Specifically, the developers mention the ability 
to work on "broken models." For example, when changing a prop- 
erty name in a class, instances of the class become invalid. The 
ModelTalk environment allows the developer to continue mod- 
eling although part of the model is temporarily in an inconsistent 
state. 

Users get accustomed to formal modeling very quickly and rely 
on the model compiler to enforce architectural constraints. Users 
complained about the tedious, manual work in writing the struc- 
tural part of the Java code, especially getters/setters. To address 
this, we extended ModelTalk with some code generation capa- 
bilities, which is outside the scope of this paper The generation of 
getters and setters provides Java type-safety, but is strictly optional, 
because the model is fully reflective. 

Users also complain about the lack of diagramming capabilities 
and interoperability with UML modeling tools. This is a topic we 
plan to address in future work. 

5.2 Organization Perspective 

An organization considering adopting a similar approach should 
take into account a substantial initial investment for building the 
infrastructure and tools. In our case, the investment was more 
than 10 man years. In addition, the ongoing maintenance of the 
development environment must be considered. Another barrier is 
the inherent complexity of such an approach. Most developers 
are not familiar with meta-modeling and need extensive training. 
Moreover, application implementation tends to be highly abstract 
and generic, which requires highly talented individuals. 

However, once such a development environment is in place, 
there are tangible benefits for the organization. First and foremost. 



all the advantages of MDD and DSML apply flT/IZl. Especially, 
time-to-market and the cost of producing customized products drop 
significantly. Second, the ability to deploy a compiled model di- 
rectly to a running system (when changes in Java are not required) 
creates a much shorter delivery route. 

6. Conclusion and Future Work 

Software solutions in the telecommunications industry typically re- 
quire massive customization. In order to reduce the cost and time- 
to-market of creating customized products, we developed MOD- 
ELTalk, a domain specific model driven framework, and used the 
framework in product development. 

An early implementation of ModelTalk was based on a gen- 
erative architecture centric MDSD approach |23|. The advantages 
of the model centric approach were evident. However, when the 
model evolved to thousands of classes, developers started to com- 
plain about the long development cycles (several minutes for each 
incremental change). This stemmed from the large amounts of gen- 
erated Java code that had to undergo compilation, packaging and 
deployment to the J2EE application server. 

In this paper we presented the new version of ModelTalk, 
which is based on an executable model, dependency injection, 
and meta-modeling; and complemented by a model compiler and 
tooling. Together these provide an enhanced user experience for 
the modeling process, similar to the programming user experience 
in modem IDEs. 

The meta-level capabilities of ModelTalk are used by devel- 
opers to create custom types of classes, fields and methods resulting 
in a domain specific modeling language. There is also support for 
resolving crosscutting concerns at the model level l3ll2l 141171 1 131 . 

We are cuiTently working on enhancing ModelTalk with run- 
time adaptability, i.e., the ability of non-programmers to change the 
model of a production system I9l ll6l . The interpretive nature of the 
ModelTalk platform provides a sound basis for achieving this 
by combining an interpretive approach with metaclass extensibil- 
ityl5]. 
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